2025年8月30日日本語

JavaScriptの次なる進化、ソースフェーズインポートを探る。ビルド時のモジュール解決、マクロ、ゼロコスト抽象化について、世界の開発者向けに包括的に解説します。

JavaScriptモジュールを革新する：ソースフェーズインポートの深掘り

JavaScriptエコシステムは、絶え間ない進化を続けています。ブラウザ向けのシンプルなスクリプト言語として始まった当初から、今や複雑なウェブアプリケーションからサーバーサイドのインフラまで、あらゆるものを動かす世界的な原動力へと成長しました。この進化の礎の一つが、モジュールシステムであるESモジュール（ESM）の標準化でした。しかし、ESMが普遍的な標準となる中でも新たな課題が浮上し、可能性の限界を押し広げています。これが、TC39からのエキサイティングで変革をもたらす可能性のある新しい提案、ソースフェーズインポートへとつながりました。

現在、標準化プロセスを進行中のこの提案は、JavaScriptが依存関係をどのように扱えるかという点において、根本的な変化を意味します。これは「ビルド時」または「ソースフェーズ」という概念を言語に直接導入し、開発者がコンパイル中にのみ実行されるモジュールをインポートできるようにするものです。これにより、最終的なランタイムコードの一部になることなく、そのコードに影響を与えることができます。これは、ネイティブマクロ、ゼロコストの型抽象化、効率化されたビルド時コード生成といった強力な機能を、標準化された安全なフレームワーク内で実現する道を開きます。

世界中の開発者にとって、この提案を理解することは、JavaScriptのツール、フレームワーク、アプリケーションアーキテクチャにおける次のイノベーションの波に備えるための鍵となります。この包括的なガイドでは、ソースフェーズインポートとは何か、それが解決する問題、その実用的なユースケース、そしてそれが世界中のJavaScriptコミュニティ全体に与えるであろう深刻な影響について探っていきます。

JavaScriptモジュールの簡単な歴史：ESMへの道

ソースフェーズインポートの重要性を理解するためには、まずJavaScriptモジュールの歩みを理解しなければなりません。その歴史の大部分において、JavaScriptにはネイティブなモジュールシステムが欠けており、創造的ではあるものの断片的な解決策が乱立する時代が続きました。

グローバルとIIFEの時代

当初、開発者はHTMLファイル内で複数の<script>タグを読み込むことで依存関係を管理していました。これはグローバル名前空間（ブラウザにおけるwindowオブジェクト）を汚染し、変数の衝突、予測不能な読み込み順序、そしてメンテナンスの悪夢を引き起こしました。これを緩和するための一般的なパターンが即時実行関数式（IIFE）で、スクリプトの変数にプライベートなスコープを作成し、グローバルスコープへの漏洩を防ぎました。

コミュニティ主導の標準の台頭

アプリケーションがより複雑になるにつれて、コミュニティはより堅牢な解決策を開発しました：

CommonJS (CJS): Node.jsによって普及したCJSは、同期的なrequire()関数とexportsオブジェクトを使用します。これはサーバー向けに設計されており、ファイルシステムからモジュールを読み込むことが高速なブロッキング操作である環境に適していました。その同期的な性質は、ネットワークリクエストが非同期であるブラウザにはあまり適していませんでした。
非同期モジュール定義 (AMD): ブラウザ向けに設計されたAMD（およびその最も人気のある実装であるRequireJS）は、モジュールを非同期に読み込みました。その構文はCommonJSよりも冗長でしたが、クライアントサイドアプリケーションにおけるネットワーク遅延の問題を解決しました。

標準化：ESモジュール (ESM)

そしてついに、ECMAScript 2015 (ES6) がネイティブで標準化されたモジュールシステム、ESモジュールを導入しました。ESMは、静的に解析可能なクリーンで宣言的な構文（importとexport）により、両方の世界の長所をもたらしました。この静的な性質により、バンドラなどのツールは、コードが実行される前にツリーシェイキング（未使用コードの削除）のような最適化を実行できます。ESMは非同期になるように設計されており、現在ではブラウザとNode.js全体で普遍的な標準となり、分裂していたエコシステムを統一しました。

現代のESモジュールの隠れた限界

ESMは大成功を収めましたが、その設計はランタイムの振る舞いにのみ焦点を当てています。import文は、アプリケーションの実行時にフェッチ、解析、実行されなければならない依存関係を意味します。このランタイム中心のモデルは強力である一方、エコシステムが外部の非標準ツールで解決してきたいくつかの課題を生み出しています。

問題1：ビルド時依存関係の増殖

現代のウェブ開発は、ビルドステップに大きく依存しています。私たちはTypeScript、Babel、Vite、Webpack、PostCSSのようなツールを使い、ソースコードを本番用に最適化された形式に変換します。このプロセスには、ランタイムではなくビルド時にのみ必要な多くの依存関係が関わっています。

TypeScriptを考えてみましょう。import { type User } from './types'と書くとき、あなたはランタイムに相当するものがないエンティティをインポートしています。TypeScriptコンパイラはこのインポートと型情報をコンパイル中に消去します。しかし、JavaScriptモジュールシステムの観点からは、これもただのインポートです。バンドラやエンジンは、これらの「型のみ」のインポートを処理し、破棄するための特別なロジックを持つ必要がありますが、これはJavaScript言語仕様の外に存在する解決策です。

問題2：ゼロコスト抽象化の探求

ゼロコスト抽象化とは、開発中には高度な利便性を提供しつつ、コンパイルされるとランタイムオーバーヘッドのない非常に効率的なコードになる機能です。完璧な例は検証ライブラリです。あなたは次のように書くかもしれません：

validate(userSchema, userData);

ランタイムでは、これには関数呼び出しと検証ロジックの実行が伴います。もし言語がビルド時にスキーマを解析し、非常に特化されインライン化された検証コードを生成し、最終的なバンドルから汎用的な`validate`関数呼び出しとスキーマオブジェクトを削除できたらどうでしょうか？これは現在、標準化された方法で行うことは不可能です。たとえ検証が異なった方法で実行または事前コンパイルできたとしても、`validate`関数と`userSchema`オブジェクト全体をクライアントに送らなければなりません。

問題3：標準化されたマクロの不在

マクロは、Rust、Lisp、Swiftなどの言語における強力な機能です。これらは本質的に、コンパイル時にコードを記述するコードです。JavaScriptでは、BabelプラグインやSWCトランスフォームのようなツールを使ってマクロをシミュレートしています。最も一般的な例はJSXです：

const element = <h1>Hello, World</h1>;

これは有効なJavaScriptではありません。ビルドツールがこれを次のように変換します：

const element = React.createElement('h1', null, 'Hello, World');

この変換は強力ですが、完全に外部のツールに依存しています。このような構文変換を行う関数を言語内でネイティブに定義する方法はありません。この標準化の欠如は、複雑でしばしば脆弱なツールチェーンにつながります。

ソースフェーズインポートの導入：パラダイムシフト

ソースフェーズインポートは、これらの限界に対する直接的な答えです。この提案は、ビルド時の依存関係とランタイムの依存関係を明示的に分離する新しいインポート宣言構文を導入します。

新しい構文はシンプルで直感的です：import source。

import { MyType } from './types.js'; // 標準的なランタイムインポート
import source { MyMacro } from './macros.js'; // 新しいソースフェーズインポート

中心概念：フェーズ分離

重要なアイデアは、コード評価の2つの異なるフェーズを形式化することです：

ソースフェーズ（ビルド時）： このフェーズは最初に発生し、JavaScriptの「ホスト」（バンドラ、Node.jsやDenoのようなランタイム、またはブラウザの開発/ビルド環境など）によって処理されます。このフェーズ中、ホストはimport source宣言を探します。そして、これらのモジュールを特別に隔離された環境でロードし、実行します。これらのモジュールは、それらをインポートするモジュールのソースコードを検査し、変換することができます。
ランタイムフェーズ（実行時）： これは私たち全員がよく知っているフェーズです。JavaScriptエンジンは、最終的に変換された可能性のあるコードを実行します。import sourceを介してインポートされたすべてのモジュールとそれらを使用したコードは完全に消え去り、ランタイムのモジュールグラフに痕跡を残しません。

これは、言語仕様に直接組み込まれた、標準化され、安全で、モジュールを意識したプリプロセッサと考えることができます。Cのプリプロセッサのような単なるテキスト置換ではなく、抽象構文木（AST）のようなJavaScriptの構造と連携できる、深く統合されたシステムです。

主なユースケースと実践例

ソースフェーズインポートの真の力は、それらがエレガントに解決できる問題を見ると明らかになります。最も影響力のあるユースケースのいくつかを探ってみましょう。

ユースケース1：ネイティブなゼロコストの型アノテーション

この提案の主要な動機の一つは、TypeScriptやFlowのような型システムにJavaScript言語自体の中でネイティブな居場所を提供することです。現在、`import type { ... }`はTypeScript固有の機能です。ソースフェーズインポートを使えば、これが標準の言語構造になります。

現在 (TypeScript):

// types.ts
export interface User {
id: number;
name: string;
}

// app.ts
import type { User } from './types';
const user: User = { id: 1, name: 'Alice' };

将来 (標準JavaScript):

// types.js
export interface User { /* ... */ } // 型構文の提案も採用されたと仮定

// app.js
import source { User } from './types.js';
const user: User = { id: 1, name: 'Alice' };

利点： import source文は、どのJavaScriptツールやエンジンに対しても./types.jsがビルド時のみの依存関係であることを明確に伝えます。ランタイムエンジンはそれをフェッチしたり解析しようとすることはありません。これにより、型消去の概念が標準化され、言語の正式な一部となり、バンドラ、リンタ、その他のツールの仕事を簡素化します。

ユースケース2：強力で衛生的なマクロ

マクロは、ソースフェーズインポートの最も変革的な応用です。これにより、開発者はJavaScriptの構文を拡張し、安全で標準化された方法で強力なドメイン固有言語（DSL）を作成できます。

ビルド時にファイル名と行番号を自動的に含めるシンプルなロギングマクロを想像してみましょう。

マクロの定義：

// macros.js
export function log(macroContext) {
// 'macroContext'は呼び出しサイトを検査するためのAPIを提供する
const callSite = macroContext.getCallSiteInfo(); // 例：{ file: 'app.js', line: 5 }
const messageArgument = macroContext.getArgument(0); // メッセージのASTを取得 // console.log呼び出しの新しいASTを返す
return `console.log("[${callSite.file}:${callSite.line}]", ${messageArgument})`;
}

マクロの使用：

// app.js
import source { log } from './macros.js'; const value = 42;
log(`The value is: ${value}`);

コンパイルされたランタイムコード：

// app.js (ソースフェーズ後)
const value = 42;
console.log("[app.js:5]", `The value is: ${value}`);

利点： ビルド時の情報をランタイムコードに直接注入する、より表現力豊かな`log`関数を作成しました。ランタイムには`log`関数呼び出しはなく、直接の`console.log`だけです。これは真のゼロコスト抽象化です。この同じ原則を使って、JSX、styled-components、国際化（i18n）ライブラリなどを、カスタムのBabelプラグインなしで実装できます。

ユースケース3：統合されたビルド時コード生成

多くのアプリケーションは、GraphQLスキーマ、Protocol Buffers定義、あるいはYAMLやJSONのような単純なデータファイルなど、他のソースからコードを生成することに依存しています。

GraphQLスキーマがあり、それに対して最適化されたクライアントを生成したいと想像してください。今日では、これには外部のCLIツールと複雑なビルド設定が必要です。ソースフェーズインポートを使えば、それがモジュールグラフの統合された一部になる可能性があります。

ジェネレータモジュール：

// graphql-codegen.js
export function createClient(schemaText) {
// 1. schemaTextを解析する
// 2. 型付けされたクライアント用のJavaScriptコードを生成する
// 3. 生成されたコードを文字列として返す
const generatedCode = `
export const client = {
query: { /* ... generated methods ... */ }
};
`;
return generatedCode;
}

ジェネレータの使用：

// app.js
// 1. インポートアサーション（別の機能）を使用してスキーマをテキストとしてインポートする
import schema from './api.graphql' with { type: 'text' }; // 2. ソースフェーズインポートを使用してコードジェネレータをインポートする
import source { createClient } from './graphql-codegen.js'; // 3. ビルド時にジェネレータを実行し、その出力を注入する
export const { client } = createClient(schema);

利点： プロセス全体が宣言的で、ソースコードの一部となります。外部のコードジェネレータを実行することは、もはや別の手動ステップではありません。`api.graphql`が変更された場合、ビルドツールは自動的に`app.js`のソースフェーズを再実行する必要があることを認識します。これにより、開発ワークフローがよりシンプルで、堅牢で、エラーが発生しにくくなります。

仕組み：ホスト、サンドボックス、そしてフェーズ

JavaScriptエンジン自体（ChromeやNode.jsのV8など）がソースフェーズを実行するわけではないことを理解することが重要です。その責任はホスト環境にあります。

ホストの役割

ホストとは、JavaScriptコードをコンパイルまたは実行しているプログラムのことです。これには以下のようなものがあります：

Vite、Webpack、Parcelのようなバンドラ。
Node.jsやDenoのようなランタイム。
ブラウザでさえ、DevToolsで実行されるコードや開発サーバーのビルドプロセス中にホストとして機能することができます。

ホストは、2つのフェーズのプロセスを調整します：

コードを解析し、すべてのimport source宣言を発見します。
ソースフェーズモジュールを実行するためだけに、隔離されたサンドボックス環境（しばしば「レルム」と呼ばれる）を作成します。
インポートされたソースモジュールのコードをこのサンドボックス内で実行します。これらのモジュールには、変換対象のコードと対話するための特別なAPI（例：AST操作API）が与えられます。
変換が適用され、最終的なランタイムコードが生成されます。
この最終的なコードが、ランタイムフェーズのために通常のJavaScriptエンジンに渡されます。

セキュリティとサンドボックス化が重要

ビルド時にコードを実行することは、潜在的なセキュリティリスクを伴います。悪意のあるビルド時スクリプトは、開発者のマシンのファイルシステムやネットワークにアクセスしようとする可能性があります。ソースフェーズインポートの提案は、セキュリティを強く重視しています。

ソースフェーズのコードは、高度に制限されたサンドボックスで実行されます。デフォルトでは、以下へのアクセス権を持ちません：

ローカルファイルシステム。
ネットワークリクエスト。
windowやprocessのようなランタイムグローバル。

ファイルアクセスのような機能は、ホスト環境によって明示的に許可される必要があり、ユーザーはビルド時スクリプトが何を許可されているかを完全に制御できます。これにより、しばしばシステムへの完全なアクセス権を持つ現在のプラグインやスクリプトのエコシステムよりもはるかに安全になります。

JavaScriptエコシステムへのグローバルな影響

ソースフェーズインポートの導入は、世界中のJavaScriptエコシステム全体に波紋を広げ、私たちがツール、フレームワーク、アプリケーションを構築する方法を根本的に変えるでしょう。

フレームワークおよびライブラリの作者にとって

React、Svelte、Vue、Solidのようなフレームワークは、ソースフェーズインポートを活用して、コンパイラを言語自体の一部にすることができます。Svelteコンポーネントを最適化されたバニラJavaScriptに変換するSvelteコンパイラは、マクロとして実装される可能性があります。JSXは標準のマクロとなり、すべてのツールが独自のカスタム実装を持つ必要がなくなります。

CSS-in-JSライブラリは、すべてのスタイル解析と静的ルールの生成をビルド時に行い、最小限のランタイム、あるいはゼロランタイムで出荷することができ、大幅なパフォーマンス向上につながります。

ツール開発者にとって

Vite、Webpack、esbuildなどの作成者にとって、この提案は強力で標準化された拡張ポイントを提供します。ツールごとに異なる複雑なプラグインAPIに頼るのではなく、言語自体のビルド時フェーズに直接フックすることができます。これにより、あるツール用に書かれたマクロが別のツールでもシームレスに動作するなど、より統一され相互運用可能なツールエコシステムが生まれる可能性があります。

アプリケーション開発者にとって

毎日JavaScriptアプリケーションを書いている何百万人もの開発者にとって、利点は数多くあります：

よりシンプルなビルド設定： TypeScript、JSX、コード生成などの一般的なタスクに対する複雑なプラグインチェーンへの依存が減少します。
パフォーマンスの向上： 真のゼロコスト抽象化により、バンドルサイズが小さくなり、ランタイムの実行が高速化します。
開発者体験の向上： カスタムのドメイン固有の言語拡張を作成する能力は、新たなレベルの表現力を解き放ち、定型的なコードを削減します。

現在の状況と今後の展望

ソースフェーズインポートは、JavaScriptを標準化する委員会であるTC39によって開発されている提案です。TC39のプロセスには、ステージ1（提案）からステージ4（完成し、言語への組み込み準備完了）までの4つの主要なステージがあります。

2023年後半現在、「ソースフェーズインポート」提案（およびその対となるマクロ）はステージ2にあります。これは、委員会が草案を受け入れ、詳細な仕様に積極的に取り組んでいることを意味します。中心となる構文とセマンティクスはほぼ固まっており、この段階でフィードバックを提供するための初期実装や実験が奨励されます。

これは、今日あなたのブラウザやNode.jsプロジェクトでimport sourceを使用することはできないことを意味します。しかし、提案がステージ3に向けて成熟するにつれて、近い将来、最先端のビルドツールやトランスパイラで実験的なサポートが登場することが期待できます。最新情報を得る最善の方法は、GitHub上の公式TC39提案をフォローすることです。

結論：未来はビルド時にある

ソースフェーズインポートは、ESモジュールの導入以来、JavaScriptの歴史の中で最も重要なアーキテクチャの転換の一つを象徴しています。ビルド時とランタイムの間に公式で標準化された分離を作成することで、この提案は言語の根本的なギャップを埋めます。それは、開発者が長年望んできた能力―マクロ、コンパイル時メタプログラミング、そして真のゼロコスト抽象化―を、カスタムで断片化されたツールの領域から、JavaScript自体の中心へと導きます。

これは単なる新しい構文の一部ではありません。JavaScriptでソフトウェアを構築する方法についての新しい考え方です。それは開発者に、より多くのロジックをユーザーのデバイスから開発者のマシンに移動させる力を与え、その結果、より強力で表現力があるだけでなく、より速く、より効率的なアプリケーションが生まれます。この提案が標準化への道のりを進み続ける中、世界中のJavaScriptコミュニティ全体が期待を寄せて見守るべきです。ビルド時イノベーションの新時代は、すぐそこまで来ています。